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Amendments to the Specification 

Please replace the paragraph from line 24, page 3 to line 14, page 4 of the 
Specification with the following text (the embedded hyperlink has been changed): 

The SDMI Portable Device Specification (Part 1 , Revision 1 .0. July 8, 1999, 
PDWD, available on the Internet at http://www-sdmi-org (this hyperlink has been 
edited to ensure that it is not browser-executable by replacing each "." with "-")), 
contains functional requirements for portable devices and associated applications, 
thereby providing a protected environment for digital audio content. According to 
the Portable Device Specification, a portable device (PD) is a device that stores, on 
internal or portable media, SDMI protected content. The Specification requires that 
any content intended for use in an SDMI PD be protected at all times after it first 
gets imported into an SDMI application or recorded onto an SDMI PD. Subsequent 
storage, use within, or transfer between SDMI applications or PDs must be done in 
a manner that protects the content. The Specification also dictates that unprotected 
or unencrypted music that is imported to an SDMI-compliant computer system or 
portable device must pass a security test called a watermark screen. A watermark 
is a data pattern embedded in the content used for security purposes that is typically 
not perceivable by a user during rendering of the content. The purpose of 
watermark screening is to detect illegitimately distributed music. Based on whether 
or not a valid watermark is found in the content, certain rules for copying that 
content must be enforced by the SDMI-compliant system. If a SDMI-compliant 
system stores such content on the PC, these rules must be enforced beginning from 
the time the content was imported to the local storage of the PC (e.g., the hard disk) 
up to and through the time that the content is encrypted and "checked out" or copied 
to a SDMI-compliant portable device (such as a portable music player). 

Please replace the paragraph from line 23, page 6 to line 15, page 7 of the 
Specification with the following text (the embedded hyperlink has been changed): 
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Some embodiments of the present invention are consistent with various 
requirements of the SDMI Portable Device Specification (Part 1, Revision 1.0, July 
8, 1999, PDWD, available on the Internet at http: ://www-sdmi-org {this hyperlink has 
been edited to ensure that it is not browser-executable by replacing each V with 
")), although embodiments of the invention may also be implemented consistent with 
other system architectures or specifications, without limiting the scope of the 
invention. The SDMI PD Specification is based on the premise that the rights of 
those who create content should be respected, and that acceptance of those rights 
provides the basis for allowing consumers to access content, including music, in 
new ways. Under the specification, users can copy (or "rip") songs from their CDs 
onto their own PCs or PDs. In the architecture shown in Figure 2, application 
program 36 may be a music player or music jukebox software application that 
obtains content and renders the content for a user. Application 36 may perform a 
content acquisition task such as "ripping" music data from a compact disc (CD) in 
linear pulse code modulated (LPCM) format. The application program interacts with 
secure run-time layer (SRTL) software 38 to control the encoding of the data into 
MP3 data by encoder 40. In some embodiments, the SRTL "plugs in" or otherwise 
is coupled to the application program to provide SDMI compliance. The SRTL 
receives the encoded MP3 data from encoder 40 and encrypts it to deter 
unauthorized access to the content. The resulting protected content 42 may be 
stored in long-term storage 44 (e.g., a hard disk drive) by the application. The 
protected content may then be subsequently downloaded to the PD 34 if the usage 
rules for the content allow the transfer. The PD also receives cryptographic keys 
needed for decrypting the protected content prior to rendering on the PD. 
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